Skip to main content

CAHN Overview

CAHN is delivered as a physical embodiment of the NIST trusted onboarding conceptual architecture

This is defined in full in the originating specific documents, but repeated below

image-20240723164739897

The continuous authorisation service is the lynchpin of this target architecture; it provides a concrete method of delivering a zero trust architecture.

BRSKI Mapping​

The following schematic shows how this abstract architecture maps onto the BRSKI variation on a WIFI network

Re

Within the above we have the following critical elements

  • Pledge or end user device which is being onboarded to the network
  • Registrar: which represents the network owner, it is the logical thing to which the pledge must "belong" before networking credentials can be provisioned
  • Routers: are the physical networking device to which the pledge will attach
  • MASA: which represents the pledge, manufactures enterprise/cloud services services which are part of the onboarding process.

The process of onboarding goes through the following abstracted phases

  1. The assumed precondition: each device has been provisioned with a unique "birthing certificate"; a secure cryptographic identity which is unique to each device
  2. Discover onboarding network: the pledge must search for and find candidate onboarding networks, which can be used to start the bootstrap process
  3. Discover registrar: once physical onboarding network has been found the device must discover one or more registrars with which they can negotiate
  4. Initiate onboarding: the pledge initiates the negotiation to join the network, via the registrar. Optionally this may involve further negotiation with the manufacturer (and other sites)
  5. Generate network credential at the registrar and simultaneously notify the "routers" and pass the credential to the pledge
  6. Store credential: the pledge should store the credential, ideally in secure storage
  7. Attempt to attach: the pledge should attempt to attach to the operational network, and the router should evaluated the request
  8. SUCCESS: the pledge is connected to the network
  9. Continuous assurance: the registrar continuously evaluates the security posture of the pledge, ejecting it if necessary.

Interfaces and processes​

To scale this solution and adapt it for multiple network types we need to define a number of interoperable interfaces and data structures, as well as implementing some key algorithms.

These are summarised conceptually below and find their detailed specification in the documents to follow

Policy oriented methods​

  • Policy data formats: these are the interoperable data structures for sharing data with the policy engine and the outside world. Concretely a family of verifiable credential data structures that embody our policy use cases.
  • Policy interchange protocols: these are a set of methods for ingesting security relevant data into the policy engine. The nature of verifiable credentials means this can be expansive. Predominately however these will be generic REST interfaces
  • Policy query engine: the algorithmic core of the policy engine that can operate on ingested VCs and perform structure queries that result in appropriate security actions.

Networking methods.​

For each networking type (5G, Wifi etc) we need to define the following

  • Onboarding discovery: a method of discovering the onboarding network and candidate registrar
  • Authentication/authorisation hooks: for each networking type we need a mechanism to hook into the authentication and authorisation flows in order to insert the continuous assurance policy enforcement.
  • Authentication/authorisation hooks: for each networking type we need a mechanism to hook into the authentication and authorisation flows in order to insert the continuous assurance policy enforcement.
  • Continuous assurance hook: to complement the authorisation hooks, we need an asynchronous interface that allows the policy engine to notify the network(s) when a mitigation action is needed
  • **Credential provisioning **: for each networking type we need a mechanism negotiate/provision the appropriate bearer level networking credential onto the pledge device

Pledge/device methods.​

For each end device for each networking type (5G, Wifi etc) we need to define the following

  • Onboarding client: the local client that will do the client side negotiation of the protocols
  • (optional)SE/TPM interface: optionally for each client we need a method to store security sensitive information (e.g credentials) in a tamper proof form

The detailed CAHN architecture makes these conceptual requirements concrete